Method and system for implementing and managing an enterprise identity management for distributed security

ABSTRACT

An Enterprise Identity Management system includes a registration component, an ownership component, and an audit component. The registration component is configured to associate a user ID with specific accounts that are accessible via a computer system. The ownership component is configured to verify the ownership of the accounts. The audit component is configured to perform periodic checks to ensure the validity of the association between the user ID and the ownership of the accounts.

FIELD OF INVENTION

This application generally relates to computer systems and moreparticularly to a method and system for managing user identities in acomputer system.

BACKGROUND OF THE INVENTION

Computer systems have evolved to the point where it is possible for auser to remotely access personal information via a computer. Forexample, one can check account balances, purchase securities, purchasegoods and check the status of goods, and the like, through the use of apersonal computer by using, for example, an Internet browser.

In providing services such as those listed above, it is desirable thatcertain types of information be accessible only by authorized users. Forexample, only the account holder should be able to access informationregarding a bank account, be able to perform certain activities (e.g.,transfers and withdrawals) on said bank account, or be able to purchasegoods.

In the past, such security has typically been provided in the form ofthe combination of a user id and a password. For example, an account ata bank may be protected by having a user “log in” to the bankingapplication by providing a user id and password. However, such asecurity system may not be as secure as desired. For example, if anunauthorized user were to become aware of the user id and password, theunauthorized user would then be able to access information and performtasks that should be limited to a select group of people.

There are several problems with the above-described scenario. Theassociation between a user ID and an account may become broken,resulting in a loss of on-line services.

For example, a user named John Smith may select, as a user ID, JSMITH1and an associated password for use with a bank account. His brother, JoeSmith may select, as a user ID, JSMITH2 and an associated password foruse with a brokerage account. After a few months of non-use, Joe Smithattempts to log-in to his brokerage account. Not remembering his userID, he thinks his user ID is JSMITH1. After unsuccessful log-inattempts, he contacts customer service.

In the prior art, the typical method of customer service verifying theuser would be to verify ownership of the account. After verifyingseveral pieces of information with Joe Smith (e.g., social securitynumber, mailing address, etc.), the customer service representative isconvinced that Joe Smith is who he says he is and grants him access tohis brokerage account using the name JSMITH1. When John Smith latertries to log-in, the same scenario may occur, as John Smith is no longerto use the JSMITH1 name that he established and contacts customerservice to change the password. The result is that the JSMITH1 user IDbecomes associated with both the accounts of John Smith and Joe Smithand customer service needs to intervene in order to grant the userstheir desired authorization level.

There is thus no system that accurately associates customer relationshipand validates the ongoing integrity of the customer relationship. Inparticular, the prior art was solely concerned with verifying theownership of the account, and not verifying the relationship between theuser ID and the account. Such a problem may be exacerbated It isdesirable to have a more robust method of managing user identities in acomputerized system.

SUMMARY OF THE INVENTION

A system of the present invention for managing identities within anenterprise includes a registration component, an ownership component,and an audit component. The registration component is configured toassociate a user ID with specific accounts that are accessible via acomputer system. The ownership component is configured to verify theownership of the accounts. The audit component is configured to performperiodic checks to ensure the validity of the association between theuser ID and the ownership of the accounts.

A method of the present invention for issuing identities associated withaccounts may first receive a request for the creation of an identity.The request is processed by a component configured to determine theexisting methods used to authenticate users. Thereafter, using variousalgorithms, questions are generated that can be used to verify theidentity of the user. Answering the questions correctly is indicative ofthe fact that the user is who he says he is, therefore the identity canbe issued.

In addition, each transaction performed under the user identity isaggregated. Positive weighting can be assigned to successfultransactions that are indicative of a ownership of the underlyingaccount, while negative weighting can be assigned to unsuccessfultransactions. Thereafter, the weightings can be analyzed to verify thatthe user identity is being used by the true owner of the underlyingaccount.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be derived byreferring to the detailed description and claims when considered inconnection with the Figures, where like reference numbers refer tosimilar elements throughout the Figures, and:

FIG. 1 presents a block diagram overview of an embodiment of the presentinvention; and

FIG. 2 is a flow chart illustrating the process by which a user createsa user ID.

DETAILED DESCRIPTION

The present invention may be described herein in terms of variousfunctional components and various processing steps. It should beappreciated that such functional components may be realized by a varietyof different hardware or structural components configured to perform thespecified functions. For purposes of illustration only, exemplaryembodiments of the present invention will be described herein. Further,it should be noted that, while various components may be suitablycoupled or connected to other components, such connections and couplingsmay be realized by a direct connection between components, or by aconnection through other components and devices.

For the sake of brevity, conventional data networking, applicationdevelopment and other functional aspects of the systems (and componentsof the individual operating components of the systems) may not bedescribed in detail herein. Furthermore, the connecting lines shown inthe various figures contained herein are intended to represent exemplaryfunctional relationships and/or physical couplings between the variouselements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical electronic transaction system.

The system may include a host server or other computing systemsincluding a processor for processing digital data, a memory coupled tosaid processor for storing digital data, an input digitizer coupled tothe processor for inputting digital data, an application program storedin said memory and accessible by said processor for directing processingof digital data by said processor, a display coupled to the processorand memory for displaying information derived from digital dataprocessed by said processor and a plurality of databases, said databasesincluding client data, merchant data, financial institution data and/orlike data that could be used in association with the present invention.As those skilled in the art will appreciate, user computer willtypically include an operating system (e.g., Windows NT, 95/98/2000,Linux, Solaris, etc.) as well as various conventional support softwareand drivers typically associated with computers. User computer can be ina home or business environment with access to a network. In an exemplaryembodiment, access is through the Internet through acommercially-available web-browser software package.

Database may be any type of database, such as relational, hierarchical,object-oriented, and/or the like. Common database products that may beused to implement the databases include DB2 by IBM (White Plains, N.Y.),any of the database products available from Oracle Corporation (RedwoodShores, Calif.), Microsoft Access or MSSQL by Microsoft Corporation(Redmond, Wash.), or any other database product. Database may beorganized in any suitable manner, including as data tables or lookuptables. Association of certain data may be accomplished through any dataassociation technique known and practiced in the art. For example, theassociation may be accomplished either manually or automatically.Automatic association techniques may include, for example, a databasesearch, a database merge, GREP, AGREP, SQL, and/or the like. Theassociation step may be accomplished by a database merge function, forexample, using a “key field” in each of the manufacturer and retailerdata tables. A “key field” partitions the database according to thehigh-level class of objects defined by the key field. For example, acertain class may be designated as a key field in both the first datatable and the second data table, and the two data tables may then bemerged on the basis of the class data in the key field. In thisembodiment, the data corresponding to the key field in each of themerged data tables is preferably the same. However, data tables havingsimilar, though not identical, data in the key fields may also be mergedby using AGREP, for example.

An embodiment of the present invention, with respect to FIG. 1, containsa registration component (102), an ownership component (104), and anaudit component (106). Registration component 102 is configured toregister new users and establish a relationship between the user ID andthe account or accounts related to the user ID. Ownership component 104is configured to define the criteria used to verify the ownership of theaccount. Audit component 106 is configured to validate the relationshipsbetween an account and a user ID on a regular basis. A user initiates aregistration process using component 110. If a customer needs help fromcustomer service (for example, the user lost his password), such aprocess can be initiated via component 112. An embodiment of the presentinvention may also be used in conjunction with pre-existing identitymanagement services (114), which has access to pre-existing serviceprofile data (118).

Communication between the parties to the transaction and the system ofthe present invention is accomplished through any suitable communicationmeans, such as, for example, a telephone network, Intranet, Internet,point of interaction device (point of sale device, personal digitalassistant, cellular phone, kiosk, etc.), online communications, off-linecommunications, wireless communications, transponder communicationsand/or the like. One skilled in the art will also appreciate that, forsecurity reasons, any databases, systems, or components of the presentinvention may consist of any combination of databases or components at asingle location or at multiple locations, wherein each database orsystem includes any of various suitable security features, such asfirewalls, access codes, encryption, de-encryption, compression,decompression, and/or the like.

The computer may provide a suitable website or other Internet-basedgraphical user interface which is accessible by users. In oneembodiment, the Internet Information Server, Microsoft TransactionServer, and Microsoft SQL Server, are used in conjunction with theMicrosoft operating system, Microsoft NT web server software, aMicrosoft SQL database system, and a Microsoft Commerce Server.Additionally, components such as Access or SQL Server, Oracle, Sybase,Informix MySQL, Intervase, etc., may be used to provide an ADO-compliantdatabase management system. The term “webpage” as it is used herein isnot meant to limit the type of documents and applications that might beused to interact with the user. For example, a typical website mightinclude, in addition to standard HTML documents, various forms, Javaapplets, Javascript, active server pages (ASP), common gateway interfacescripts (CGI), extensible markup language (XML), dynamic HTML, cascadingstyle sheets (CSS), helper applications, plug-ins, and the like.

In establishing a user ID, it is preferable that a set of criteria bepre-established to facilitate relating a user ID to an account. In thecontext of financial services, for example, a financial service providerhas a large set of data related to each account. In the instance where auser wishes to establish a user ID, registration component 102 hasaccess to subsets of that data, allowing an establishment of arelationship between a user ID and all accounts owned by the user. Forexample, a user wishes to access his bank account on-line. During theregistration process, registration component 102 can determine that, forexample, the user also owns a brokerage account and a credit accountfrom the same provider of the bank account. Thus, the user IDestablished by registration component 102 is associated with the bankaccount, the brokerage account, and the credit account.

Ownership component 104 is configured to establish rules to help ensurethat adequate ownership information is obtained from the user duringauthentication. For example, if a user wishes to associate a user ID toa brokerage account, ownership component 104 is configured to determinethe criteria needed to verify that the identity of the person requestingthe ID is the owner of the brokerage account. A user wishing toassociate a user ID to another type of account with less need forsecurity (e.g., the ability to check the balance of a credit account)may not utilize the same criteria. For example, access to a brokerageaccount may require that the user input a name, social security number,date of birth, and verify various bits of information. But access to abalance checking feature may only require the user to know the name andaccount number.

For a business organization with multiple business lines, ownershipcomponent 104 may be configured to evaluate each business line todetermine the authentication process each business line uses.Thereafter, ownership component 104 uses an algorithm to generate a setof questions or criteria that can be used by registration component 102to verify that the requesting user is the owner of the account.

With respect to FIG. 2, the process by which a user establishes a userID with a business comprising multiple business lines is illustrated. Auser accesses a business system and requests a user ID (step 202).Registration component 102 is activated and determines which accountsfrom the various businesses are to be associated with the user ID. In atypical usage, the user selects the various business lines he wishes tobe associated with the user ID. Thereafter, ownership component 104 isactivated (step 204). Ownership component 104 is configured to determinethe various schemes used by the selected business lines to authenticateusers (step 206). Then the various authentication processes are joinedin a rules-based algorithm to generate specific questions to be asked ofthe user attempting to obtain a user ID (step 208). After the usercorrectly answers the generated questions, registration component 102supplies the requested credentials to the user, indicating that the userwas validated. (Step 210). The credentials may be in the form of a userID/password combination, or other such access control means now known ordeveloped in the future.

Even though a set of relationships is robustly validated at the time ofthe creation of the relationships, the relationships can deteriorateover time, for a number of reasons. For example, account expiration,account re-issuance (e.g., due to a stolen credit card), change inmarital status (resulting in a no longer valid card that was issued to aspouse), change in address, and the like. In order to maintain anaccurate management of identities, it is preferable to periodicallymonitor the relationships.

An embodiment of audit component 106 of the present invention utilizes amathematical weighting function that assigns values to specificinteractions captured by the system. Interactions that serve to confirmthe identity of the user are assigned positive values. Examples of thesetypes of interaction include the payment of balances, the receipt ofmerchandise, and similar transactions where it is unlikely that anunauthorized user performed the transaction. Interactions that serve toundermine the identity of the user are assigned negative values.Examples of such interactions include non-payment of bills, requests toreceive merchandise at alternate locations.

Additionally, certain interactions may be weighted in aggregate form. Inother words, some combinations of events may have relationships witheach other. For example, a series of identity-undermining events mayhave an aggregate negative weighting that exceeds the individualnegative weightings described above.

Aggregated behaviors may also include usage behaviors that can becaptured as patterns using, for example, conventional pattern matchingalgorithms. Each usage can be compared to a typical usage pattern.Typical usage may include the typical tasks performed by the user, thelocation of the user (which can be determined, for example, via the IPaddress or addresses from which they typically connect). This patterndata may be updated at regular intervals. For example, each time theuser accesses the system, a similarity score can be computed thatindicates the similarity of the transaction to previous transactions.Therefore, each usage of the system establishes a usage history for theuser. Thus, previous usage can be logged and compared to each subsequentusage.

Other information that can be stored includes more detailed informationregarding the console the user is using. For example, the type ofbrowser, the type of computer, the operating system, and the like, maybe accessible when a user accesses the computer system.

Another embodiment of the present invention records various informationabout a user each time the user accesses the computer system. Examplesof the information collected include the IP address from which the useraccesses the computer system; the browser being used; the transactionsperformed on the computer system; the time of the access; and the like.This information may be collected each time the user accesses thecomputer system. At each subsequent access to the computer system, suchinformation can be compared to connection information previouslycollected. If the information is very similar, the user can continue toperform transactions. However, if the information is different, moreinformation may be requested from the user to confirm the user'sidentity.

The certainty measure may also be increased through the usage ofspecific questions that only a particular person would know the answerto, prior to allowing the user to perform certain transactions. Forexample, additional questions may be asked when a user attempts totransfer funds, obtain a cash advance, or other such transactions thathave been determined to require more security to perform. Such questionsare more specific and would only be known to the card holder, and not tothose who, for example, steal a credit card. Such a question may includequeries regarding previous purchases, questions regarding associatedaccounts, and the like, in addition to questions regarding the accountholder, such as address, social security number, date of birth, and thelike. The questions asked can be determined algorithmically usingvarious methods. Correct answers to such questions not only allow theuser to perform the requested tasks, but also increase theabove-described certainty measure of the user.

It can thus be seen that the above-described problems can be eliminatedby an embodiment of the present invention. For example, it would not bepossible for the owner of user ID JSMITH2 to obtain access to the userID JSMITH1, as the ownership component would determine that, although heis the owner of an account, he is not the owner of the accountassociated with the JSMITH1 user ID.

The present invention is described herein with reference to blockdiagrams, flowchart illustrations of methods, systems, and computerprogram products according to various aspects of the invention. It willbe understood that each functional block of the block diagrams and theflowchart illustrations, and combinations of functional blocks in blockdiagrams and flowchart illustrations, respectively, may be implementedby computer program instructions. These computer program instructionsmay be loaded on a general purpose computer, special purpose computer,or other programmable data processing apparatus to produce a machine,such that the instructions which execute on the computer or otherprogrammable data processing apparatus create means for implementing thefunctions specified in the flowchart block or blocks.

It will be appreciated, that many applications of the present inventioncould be formulated. One skilled in the art will appreciate that thenetwork may include any system for exchanging data or transactingbusiness, such as the Internet, an intranet, an extranet, WAN, LAN,satellite communications, and/or the like. It is noted that the networkmay be implemented as other types of networks, such as an interactivetelevision (ITV) network. The users may interact with the system via anyinput device such as a keyboard, mouse, kiosk, personal digitalassistant, handheld computer (e.g., Palm Pilot®), cellular phone and/orthe like. Similarly, the invention could be used in conjunction with anytype of personal computer, network computer, workstation, minicomputer,mainframe, or the like running any operating system such as any versionof Windows, Windows NT, Windows2000, Windows 98, Windows 95, MacOS,OS/2, BeOS, Linux, UNIX, Solaris or the like. Moreover, although theinvention is frequently described herein as being implemented withTCP/IP communications protocols, it will be readily understood that theinvention could also be implemented using IPX, Appletalk, IP-6, NetBIOS,OSI or any number of existing or future protocols. Moreover, the systemcontemplates the use, sale or distribution of any goods, services orinformation over any network having similar functionality describedherein.

The computing units may be connected with each other via a datacommunication network. The network may be a public network and assumedto be insecure and open to eavesdroppers. In the illustratedimplementation, the network may be embodied as the internet.

In this context, the computers may or may not be connected to theinternet at all times. For instance, the customer computer may employ amodem to occasionally connect to the internet, whereas the bankcomputing center might maintain a permanent connection to the internet.

Specific information related to the protocols, standards, andapplication software utilized in connection with the Internet may not bediscussed herein. For further information regarding such details, see,for example, DILIP NAIK, INTERNET STANDARDS AND PROTOCOLS (1998); JAVA 2COMPLETE, various authors, (Sybex 1999); DEBORAH RAY AND ERIC RAY,MASTERING HTML 4.0 (1997). LOSHIN, TCP/IP CLEARLY EXPLAINED (1997). Allof these texts are hereby incorporated by reference.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded on a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

In the foregoing specification, the invention has been described withreference to specific embodiments. However, it will be appreciated thatvarious modifications and changes can be made without departing from thescope of the present invention. The specification and figures are to beregarded in an illustrative manner, rather than a restrictive one, andall such modifications are intended to be included within the scope ofpresent invention.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. No elementdescribed herein is required for the practice of the invention unlessexpressly described as “essential” or “critical”.

1. A method implemented by a computer for facilitating issuance of anidentity associated with an account comprising: receiving at saidcomputer, a request for said identity, wherein said identity isassociated with an account; determining, at said computer,authentication rules associated with said account, whereinauthentication questions to be asked of a user are based upon saidauthentication rules; issuing, by said computer, said identity to saiduser when at least a portion of said authentication questions arecorrectly answered; monitoring, by said computer, changes in arelationship between said user and said identity over a period of timeto periodically perform an automatic adjustment of said authenticationquestions upon a deterioration of said relationship, wherein saiddeterioration of said relationship is based upon user activity;evaluating a current transaction of said user; comparing said currenttransaction to previous transactions performed by said user; and,assigning a positive weight for a similar transaction by said user. 2.The method of claim 1, further comprising assigning a negative weightfor a non-similar transaction by said user.
 3. A method implemented by acomputer for facilitating issuance of an identity associated with anaccount comprising: receiving, at said computer, a request for saididentity, wherein said identity is associated with an account;determining at said computer, authentication rules associated with saidaccount, wherein authentication questions to be asked of a user arebased upon said authentication rules; issuing, by said computer, saididentity to said user when at least a portion of said authenticationquestions are correctly answered; monitoring, by said computer, changesin a relationship between said user and said identity over a period oftime to periodically perform an automatic adjustment of saidauthentication questions upon a deterioration of said relationship,wherein said deterioration of said relationship is based upon useractivity; assigning a positive weight for a successful transaction bysaid user on said account, wherein said successful transaction is basedon security requirements of said account and risk factors relating tovarious transaction types associated with said account; assigning anegative weight for an unsuccessful transaction by said user on saidaccount; and aggregating said positive and negative weights to determinea usage history of said user.
 4. The method of claim 3, furthercomprising: analyzing said aggregation of said positive weights and saidnegative weights to determine a validity of said identity.
 5. The methodof claim 4, further comprising removing a relationship between saididentity and said account when said analyzing step fails to meet apredetermined criteria.